Captive portals are used by venues that provide free Wi-Fi hot spots for end users. The captive portal is a Web page that the end user is obligated to visit and interact with before access to free Wi-Fi is made available. Example venues may be, but are not limited to, corporate offices for guest login, airports, hotels, coffee shops, etc. A captive portal enables a network administrator to allow authorized users Internet access. In a captive portal network the Wi-Fi authentication is always Open Authentication and real user authorization is carried out through the Web page where the end user interacts to enter login credentials.
One of the most widely used implementation mechanisms is HTTP redirection. Using HTTP redirection, a gateway on an AP network (or the AP itself with Captive Portal support) hijacks an HTTP request from a connected STA and responds with a redirected URL in the HTTP response. Following this, the HTTP browser on the STA (Wi-Fi client device) opens the redirected URL containing a captive portal login Web page.
When a device, such as a mobile phone or laptop, running a particular Operating System (OS) connects to a Wi-Fi network with open authentication, the OS on the device carries out steps to detect whether or not the network has a captive portal. The device OS sends out a HTTP-GET request to a corresponding special website hosted by the venue. There is an expected response the device OS knows it is expected to receive when accessing the special website. When the OS device receives the HTTP-GET response, it compares the content of the special website with the expected response. If the content matches, the device OS concludes that there is no captive portal on the Wi-Fi network that it is connected to. When the content does not match, the device OS concludes that there is a captive portal on the Wi-Fi network. This occurs because of the redirection of the HTTP-GET request from the device by the captive portal on the network. The captive portal login page is sent as a response to the HTTP-GET request from the device. The end user can then login with credentials.
The method described above has several drawbacks. Operating System companies are required to host special websites on the Internet which requires cost to set up and maintain to ensure the website is always up and running. The detection mechanism is based on HTTP protocol and therefore may not be suitable for small embedded devices, such as wearables or Internet of Things (IOT) devices, which typically operate without HTTP protocol. The method relies on HTTP protocol exchange between a host and a hosted HTTP server and is time consuming. Carrying out an HTTP protocol exchange for every Wi-Fi connection also adds traffic to the Internet.
There is a need for an efficient method for captive portal detection.